Humanidades

A IA pode realmente programar?
Estudo mapeia os obstáculos para a engenharia de software autônoma Uma equipe de pesquisadores mapeou os desafios da IA no desenvolvimento de software e delineou uma agenda de pesquisa para impulsionar o campo.
Por Rachel Gordon - 24/07/2025


Um novo artigo de pesquisadores do MIT CSAIL mapeia as diversas tarefas da engenharia de software além da geração de código, identifica gargalos e destaca as direções de pesquisa para superá-los. O objetivo: permitir que os humanos se concentrem no design de alto nível, enquanto o trabalho rotineiro é automatizado. Créditos: Imagem: Alex Shipps/MIT CSAIL, usando recursos do Shutterstock e Pixabay


Imagine um futuro em que a inteligência artificial assuma silenciosamente a árdua tarefa do desenvolvimento de software: refatorar códigos complexos, migrar sistemas legados e identificar condições de corrida, para que engenheiros humanos possam se dedicar à arquitetura, ao design e aos problemas genuinamente novos que ainda estão além do alcance de uma máquina. Avanços recentes parecem ter aproximado esse futuro de forma tentadora, mas um novo artigo de pesquisadores do Laboratório de Ciência da Computação e Inteligência Artificial (CSAIL) do MIT e de diversas instituições colaboradoras argumenta que essa potencial realidade futura exige uma análise aprofundada dos desafios atuais. 

Intitulado “ Desafios e caminhos para a IA na engenharia de software ”, o trabalho mapeia as muitas tarefas de engenharia de software além da geração de código, identifica os gargalos atuais e destaca as direções de pesquisa para superá-los, com o objetivo de permitir que os humanos se concentrem no design de alto nível enquanto o trabalho de rotina é automatizado. 

“Todo mundo está falando sobre como não precisamos mais de programadores, e agora existe toda essa automação disponível”, diz Armando Solar?Lezama, professor de engenharia elétrica e ciência da computação do MIT, pesquisador principal do CSAIL e autor sênior do estudo. “Por um lado, a área fez um progresso tremendo. Temos ferramentas muito mais poderosas do que qualquer outra que já vimos. Mas também há um longo caminho a percorrer para realmente atingirmos a promessa completa de automação que esperaríamos.”

Solar-Lezama argumenta que narrativas populares frequentemente reduzem a engenharia de software à "parte da programação de graduação: alguém lhe entrega uma especificação para uma pequena função e você a implementa, ou resolve entrevistas de programação no estilo LeetCode". A prática real é muito mais ampla. Inclui refatorações cotidianas que aprimoram o design, além de migrações abrangentes que movem milhões de linhas de COBOL para Java e remodelam negócios inteiros. Exige testes e análises ininterruptos — fuzzing, testes baseados em propriedades e outros métodos — para detectar bugs de simultaneidade ou corrigir falhas de dia zero. E envolve a rotina de manutenção: documentar código com décadas de existência, resumir históricos de alterações para novos colegas de equipe e revisar pull requests quanto a estilo, desempenho e segurança.

A otimização de código em escala industrial — pense no reajuste de kernels de GPU ou nos refinamentos implacáveis e multicamadas por trás do mecanismo V8 do Chrome — continua teimosamente difícil de avaliar. As métricas mais populares de hoje foram projetadas para problemas curtos e independentes e, embora os testes de múltipla escolha ainda dominem a pesquisa em linguagem natural, eles nunca foram a norma em IA para código. O parâmetro de fato da área, o SWE-Bench, simplesmente pede a um modelo para corrigir um problema do GitHub: útil, mas ainda semelhante ao paradigma do "exercício de programação de graduação". Ele aborda apenas algumas centenas de linhas de código, corre o risco de vazamento de dados de repositórios públicos e ignora outros contextos do mundo real — refatorações assistidas por IA, programação em pares humano-IA ou reescritas críticas de desempenho que abrangem milhões de linhas. Até que os benchmarks se expandam para capturar esses cenários de maior risco, mensurar o progresso — e, portanto, acelerá-lo — continuará sendo um desafio em aberto.

Se a medição é um obstáculo, a comunicação homem-máquina é outro. O primeiro autor, Alex Gu, estudante de pós-graduação em engenharia elétrica e ciência da computação do MIT, vê a interação atual como "uma linha tênue de comunicação". Quando solicita a um sistema que gere código, ele frequentemente recebe um arquivo grande e não estruturado e até mesmo um conjunto de testes unitários, mas esses testes tendem a ser superficiais. Essa lacuna se estende à capacidade da IA de usar efetivamente o conjunto mais amplo de ferramentas de engenharia de software, de depuradores a analisadores estáticos, das quais os humanos dependem para controle preciso e compreensão mais profunda. "Eu realmente não tenho muito controle sobre o que o modelo escreve", diz ele. "Sem um canal para a IA expor sua própria confiança — 'esta parte está correta... esta parte, talvez verifique novamente' — os desenvolvedores correm o risco de confiar cegamente em uma lógica alucinada que compila, mas entra em colapso na produção. Outro aspecto crítico é fazer com que a IA saiba quando recorrer ao usuário para esclarecimentos." 

A escala agrava essas dificuldades. Os modelos atuais de IA enfrentam dificuldades profundas com grandes bases de código, muitas vezes abrangendo milhões de linhas. Os modelos de base aprendem com o GitHub público, mas "a base de código de cada empresa é diferente e única", diz Gu, tornando as convenções de codificação proprietárias e os requisitos de especificação fundamentalmente fora da distribuição. O resultado é um código que parece plausível, mas chama funções inexistentes, viola regras de estilo internas ou falha em pipelines de integração contínua. Isso frequentemente leva a um código gerado por IA que "alucina", ou seja, cria conteúdo que parece plausível, mas não se alinha com as convenções internas, funções auxiliares ou padrões arquitetônicos específicos de uma determinada empresa. 

Os modelos também costumam realizar recuperações incorretas, pois recuperam código com nome semelhante (sintaxe) em vez de funcionalidade e lógica, que é o que um modelo pode precisar para saber como escrever a função. "Técnicas de recuperação padrão são facilmente enganadas por trechos de código que fazem a mesma coisa, mas parecem diferentes", diz Solar-Lezama. 

Os autores mencionam que, como não há uma solução mágica para essas questões, eles estão pedindo, em vez disso, esforços em escala comunitária: mais ricos, com dados que capturem o processo de desenvolvedores escrevendo código (por exemplo, qual código os desenvolvedores mantêm versus descartam, como o código é refatorado ao longo do tempo, etc.), suítes de avaliação compartilhadas que medem o progresso na qualidade da refatoração, longevidade da correção de bugs e correção da migração; e ferramentas transparentes que permitem que os modelos exponham incertezas e convidem a direção humana em vez da aceitação passiva. Gu enquadra a agenda como um "chamado à ação" para colaborações maiores de código aberto que nenhum laboratório sozinho conseguiria reunir. Solar-Lezama imagina avanços incrementais — "resultados de pesquisa explorando cada um desses desafios separadamente" — que realimentam as ferramentas comerciais e gradualmente movem a IA de um ajudante de preenchimento automático para um verdadeiro parceiro de engenharia.

“Por que tudo isso importa? Softwares já sustentam finanças, transporte, saúde e as minúcias da vida cotidiana, e o esforço humano necessário para construí-los e mantê-los com segurança está se tornando um gargalo. Uma IA que possa assumir o trabalho pesado — e fazê-lo sem introduzir falhas ocultas — liberaria os desenvolvedores para se concentrarem em criatividade, estratégia e ética”, diz Gu. “Mas esse futuro depende do reconhecimento de que a complementação de código é a parte fácil; a parte difícil é todo o resto. Nosso objetivo não é substituir programadores. É amplificá-los. Quando a IA puder lidar com o tedioso e o assustador, os engenheiros humanos poderão finalmente dedicar seu tempo ao que só os humanos podem fazer.”

“Com tantos novos trabalhos surgindo em IA para programação, e a comunidade frequentemente acompanhando as últimas tendências, pode ser difícil parar e refletir sobre quais problemas são mais importantes a serem enfrentados”, afirma Baptiste Rozière, cientista de IA da Mistral AI, que não participou do artigo. “Gostei de ler este artigo porque ele oferece uma visão geral clara das principais tarefas e desafios da IA para engenharia de software. Ele também delineia direções promissoras para pesquisas futuras na área.”


Gu e Solar-Lezama escreveram o artigo com o professor Koushik Sen, da Universidade da Califórnia em Berkeley, e os alunos de doutorado Naman Jain e Manish Shetty, o professor assistente Kevin Ellis, da Universidade Cornell, e o aluno de doutorado Wen-Ding Li, a professora assistente Diyi Yang, da Universidade Stanford, e o aluno de doutorado Yijia Shao, e o novo professor assistente Ziyang Li, da Universidade Johns Hopkins. O trabalho deles foi financiado, em parte, pela National Science Foundation (NSF), patrocinadores industriais e afiliados do SKY Lab, Intel Corp., por meio de uma bolsa da NSF, e pelo Escritório de Pesquisa Naval.

Os pesquisadores estão apresentando seu trabalho na Conferência Internacional sobre Aprendizado de Máquina (ICML). 

 

.
.

Leia mais a seguir